WARNING:
JavaScript is turned OFF. None of the links on this concept map will
work until it is reactivated.
If you need help turning JavaScript On, click here.
此概念图以 IHMC CmapTools 创建, 内含信息有关于: 第四章表達系統的微觀設計:「物件圖」(Object Diagram)、「狀態機圖」(State Machine Diagram)、「時序圖」(Timing Diagram), 信仁醫院案例背景描述 是 專案開發人員:架構師,我仔細看過領域模 型,但是有些部分我不大清楚,你可否解釋 一下? HSDe軟體架構師:當然,沒有問題。 專案開發人員:我已經把相關問題作了一些 整理,請看:最主要的疑惑有兩個,第一個 地方是在「醫生」類別和「住院事件」之間 的「關聯」關係,為什麼不實作成一個「關 聯」,並標示為2..",而一定要利用兩個「關 聯」來實作?其次則是有關病床、健保病床 以及自費病床的實作方式,為什麼不在病床 的「計算費用」操作中,直接把企業邏輯寫 在其中,而一定要獨立兩個類別來處理? HSDe軟體架構師:喔,有關第一個問題,主 要是由於當初我和信仁醫院的特助針對領域 模型討論時,將領域上的重要概念轉換後的 結果。根據領域中的概念,面對一個住院事 件時,醫生有可能扮演兩種不同的角色,是 主治醫師,另一則是住院醫師,由於對於住 院事件而言,兩個醫師所擔任的工作非常類 似,因此,我認為不需要獨立兩個類別,單 純用「關聯」關係中的「角色」就可以區分 。至於第二個問題,其實也是我要特別跟團 隊説明的,在未來的程式寫作上,有兩個基 本要求: ■針對領域模型中的所有類別,每一個 Operation內部的程式碼不可以超過20行以上。 ■在所有的程式碼中,不允許使用if-then-else 的敘述。 也正是因為這樣,所以對於「計算費用」的 這個操作,我會利用三個類別來實作。 專案開發人員:有關第一個問題,我還是不 大瞭解,可不可以舉個例子來説明?至於第 二個問題,嗯...我們團隊會盡力達成的,哈! HSDe軟體架構師:好的,針對第一個問題, 我會直接用UML的圖形來解釋,屆時你也可 以把這張圖形拿去你的開發團隊來作為説明 。, 物件圖 包括 信仁醫院住出院系統的物件圖範例, 病床狀態的狀態機圖範例 是 根據這個類別,病床狀態的移轉和病床的幾個 「操作」有關係。下圖即是利用狀態機圖來表 達這兩者間的關係。, 物件圖的基本認識 是 物件圖的目的是在描述「特定時間點」中, 所有物件在系統中的結構;也因此,你可以 把物件圖當成系統在某一個時間點的「快照 」(snapshot)。, 總結 是 狀態機圖的主要目的在陳述系統中有關事件或 是物件的狀態移轉。一般來說,狀態機圖可以 利用在以下的開發過程中: 1若是系統設計人員設計了某一個類別的狀態 ,而該狀態是透過該類別的事件(行為)來改變 的話,系統設計人員可以在該類別中繪製一張 狀態機圖來陳述該狀態的細節設計 2對於GUI的設計人員來說,若是某一個畫面中 的控制項(Control Item)會受到其他控制項狀態轉 移的影響,則可以針對該畫面設計一張狀態機 圖來作為輔助的說明。 3對於系統架構師來說,若是整體的作業流程中 ,有某些系統狀態的移轉會受到特定的條件限 制,則也可以透過狀態機圖來描述這些相關的 限制式。, 信仁醫院案例背景描述 緣由 HSDe軟體架構師在設計「病床」類別的狀態時 ,發現了一個情況:在「病床」的狀態中,有 一個「Registered」的狀態,這個狀態會「鎖住 」某一個特定的「病床」的物件;然而,若是 遲遲沒有「確認預定」事件發生的話,那麼該 物件就永遠停留在「Registered」的狀態。因此 ,HSDe軟體架構師決定打電話和信仁醫院特助 針對這個狀況進行討論。, 第四章表達系統的微觀設計:「物件圖」(Object Diagram)、「狀態機圖」 (State Machine Diagram)、「時序圖」(Timing Diagram) 資料來源根據『UML團隊開發流程與管理』 包括 狀態機圖, 物件圖的基本認識 是 物件圖的主要元素和「溝通圖的基本認識」 所介紹的溝通圖非常類似,甚至可以說是溝 通圖的子集合(subset)。, 信仁醫院案例背景描述 緣由 當專案設計人員實際開始進行程式設計時, 對於HSDe軟體架構師所設計的領域模型, 覺得有些地方不清楚,因此,彼此又進行了 一次內部討論,以下是該次內部討論的相關 情節。, 時序圖 包括 病床狀態的時序圖範例, 問題與分析 是 從大的方向來看,在傳統的「資訊管理系統」 (MIS)領域中,其實比較少著墨於狀態轉移的 塑模(Modeling);狀態移轉的相關理論,反而 在類似「嵌入式系統」(EmbeddedSystem)及「 即時性系統」(Real-timeSystem)的設計上,被 應用的比較廣泛。, 總結 是 系統結構中有相當多細微部分的設計,需要使 用「微觀設計」的設計圖來表達。在UML中, 表達微觀設計的設計圖主要有三張圖形,分別 是物件圖、狀態機圖以及時序圖。, 狀態機圖的基本認識 是 ■複合狀態(Composite State,or State Machine) 複合狀態指的是在某個狀態中,有其自行的 狀態轉移,如圖4-7中的「安裝軟!體」就是 一個複合狀態。 ■歷史狀態(History State) 每個狀態都可以有其歷史狀態,這是一個屬 於「記憶」性質的狀態,可以記住在某一個 特定時間點的狀態歷史狀態的UML表示法為 「原始狀態」。 ■轉移(Transition) 狀態與狀態之間,是利用「轉移」來表達期 間的關係,這用來表示其狀態的變化情形。 轉移的圖形是「→」。 ■事件驅動(EventTrigger) 當狀態是因為某個事件發生而造成狀態的轉 移,此時,在「轉移」的關係上可以標示該 事件,這稱之為「事件驅動」。 ■限制條件(GuardCondition) 若是狀態轉移的發生是因為某個特定的限制 條件而發生,那麼在「轉移」的關係上,可 以標示這個限制條件限制條件在UML表達上 ,是用一個中括弧「[]」來表達。, 狀態機圖 包括 問題與分析, 第四章表達系統的微觀設計:「物件圖」(Object Diagram)、「狀態機圖」 (State Machine Diagram)、「時序圖」(Timing Diagram) 資料來源根據『UML團隊開發流程與管理』 包括 時序圖, 第四章表達系統的微觀設計:「物件圖」(Object Diagram)、「狀態機圖」 (State Machine Diagram)、「時序圖」(Timing Diagram) 資料來源根據『UML團隊開發流程與管理』 包括 物件圖, 第四章表達系統的微觀設計:「物件圖」(Object Diagram)、「狀態機圖」 (State Machine Diagram)、「時序圖」(Timing Diagram) 資料來源根據『UML團隊開發流程與管理』 是 這三張圖,都是在描述有關某個特定的狀況 下的系統運作情圖形,也因此,我們特別把 這三張圖形定義為「系統的微觀設計」。, 物件圖 包括 物件圖的基本認識, 物件圖 包括 問題與分析, 第四章表達系統的微觀設計:「物件圖」(Object Diagram)、「狀態機圖」 (State Machine Diagram)、「時序圖」(Timing Diagram) 資料來源根據『UML團隊開發流程與管理』 包括 總結